Hi Tom,
We have a 5-axis G-code program where the interpreter/motion planner is combining g1 moves on consecutive blocks, even though (according to my understanding, anyway) it should not do that. Here is the code snippet: f600 g1 x... y... z... a... b... g1 z... The second block's z... is more negative than the 1st. It so happens that the 1st block's xyza are the same (or very close to) the previous block's, so there is only a movement in the B axis for the first block. What happens is that both blocks are combined so that the first block's z is ignored and there is a "diagonal" move. If I change the 2nd block's g1 to a g0, then it works as expected. Also, if I put a different feed rate on the 2nd block, it also works e.g. f600 g1 x... y... z... a... b... f601 g1 z... Unfortunately, I can't give you a working snippet since I can't reproduce this using normal hard-coded coordinates. Our program actually generates the coordinates dynamically using probing results. Just in case it is something to do with using # variables, the subroutine we are using is included below. The two relevant blocks are commented "move to next point" and "rapid down above material". The o111 routine is called for each point. M102 retrieves the probe data from the kflop. Most of the time, it works, but out of the 13 test points that we have, 3 of them exhibit this behavior, and they are all for B-only moves. Regards, SJH
#11=-0.2 (drill depth)
#14=10 (retract height above)
#16=0.5 (start above height)
#32=600 (feed rate)
#33=1 (use g1)
...
o111 (operation 1)
m102 p0 q61 (get next point to #61..66; #66 is status)
#5020=#66 (set status code in expected variable for check)
m98 p100 (check OK probe)
f#32 g#33 x#61 y#62 z[#63+#14] a#64 b#65 (move to next point)
z[#63+#16] (rapid down above material)
f#12 g1 z[#63+#11] (drill it)
g0 z[#63+#14] (retract)
m99
|
|
.png){kind=link}